REMARKS 

Applicant respectfully requests the consideration of the following remarks and the 
reconsideration of the application. 

Claims 1, 10, 23, 34, 43, 52 and 65 were rejected under 35 U.S.C. 1 12, second 
paragraph, as being indefinite. Claims 1, 10, 23, 34, 43, 52 and 65 are currently amended to 
correct errors so that the terms used have sufficient antecedent basis. 

Claims 4, 17, 39, 46 and 59 were rejected under 35 U.S.C. 1 12, first paragraph as 
failing to comply with the enablement requirement. Claims 1-3, 6, 8-10, 15-16, 19, 21-23, 
27-28, 30, 32-34, 37-38, 41-45, 48, 50-52, 57-58, 61 and 63-65 were rejected under 35 
U.S.C. 102(e) as being anticipated by Carter (U.S. Patent No. 6,201,61 1). Claims 5, 18, 29, 
40, 47 and 60 were rejected under 35 U.S.C. 103(a) as being unpatentable over Carter., 
Claims 7, 20, 31, 49 and 62 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Carter in view ofManiwa (U.S. Patent No. 5,768,483). Claims 11-12, 14,24-25,35-36,53- 
54, 56 and 66-67 were rejected under 35 U.S.C. 103(a) as being unpatentable over Carter in 
view of Koga (EP Patent No. 1,026,578). Claims 13, 26, 55 and 68 were rejected under 35 
U.S.C. 103(a) as being unpatentable over Carter, in view of Koga and further in view of 
Mogul (U.S. Patent No. 6,243,761). Applicant respectfully disagrees. 

Claims 4, 17, 39, 46 and 59 were rejected under 35 U.S.C. 112, first paragraph as 
failing to comply with the enablement requirement, since these claims recite the limitation of 
"no running operating system." Applicant respectfully disagrees. The Office Action stated 
that "It is not generally well known to operate network-enabled PDAs without an operating 
system." However, Applicant respectfully submits that the specification teaches to use at 
least a particular type of PDAs, which is the subject matter of the present application and a 
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number of prior applications of the same inventor of the present application, such as U.S. 
Patent Applications No. 09/496,172, 09/501,585, 09/504,807, 09/504,808 and 09/504,809. A 
description of such a PDA is provided on pages 5-8 of the specification. Unlike a traditional 
PDA device (e.g., a Palm Pilot computer running a Palm operation system or a hand held 
computers running Windows CE operating system), the PDA device according to the 
inventor does not require a powerful microprocessor. Further, it may not run an operating 
system. 

In one embodiment, the portable device according to the inventor has the ability to 
receive and display an image that is rendered from information, such as a web page, at a 
remote server. According to embodiments of the present invention, the server renders the 
entire web page into an image. Thus, the display of an image on the portable device does not 
require complicated software applications, such as a traditional web browser that is typically 
used on a client to render a web page for display. Therefore, the portable device does not 
need a traditional web browser running on top of an operating system, although embodiments 
of the present invention can also be used on general purpose PDAs and computers running 
various operating systems. From the description of the present application, it is understood 
that the portable device may not be a general purpose PDA that needs an operating system. 
A portable device according one embodiment of the present invention receives and displays 
images, in communication with the remote server. It is generally known how to implement 
electronic circuitry to communicate with a remote server, electronic circuitry to decompress 
and display a compressed image, electronic circuitry to control a display device and 
electronic circuitry to receive user input. 

In one embodiment, a peripheral device (e.g., a printer or a scanner) is connected to 
portable device. The portable device provides a two-way communication channel between 
the peripheral device and the server so that the peripheral device is under the control of the 
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server. When the portable device transmits a message to the server to operate the peripheral 
device, the server generates control information to operate the peripheral device. In a 
traditional web application, the server transmits the web page, including HTML, JPEG and 
JAVA to a client; the client then uses a traditional web browser to render the web page for 
display. However, in one example according to the present application, the portable device 
displays an image that is rendered at the server from the entire web page that may include 
various components, such as text, HTML hyper-links, JPEG, and JAVA. When the portable 
device sends a message to the server to print the web page, the server uses the printer that is 
connected to the portable device to print the web page, since the server has the web page and 
the two-way communication channel to control the printer that is connected to the portable 
device. 

Thus, from the description of the application, a person skilled in the art understood 
how to implement such a portable device, without a running operating system, for a cost 
effective Internet access solution. Applicant respectfully requests the withdrawal of the 
rejection under 35 U.S.C, 1 12, first paragraph. 

Claims 1-3, 6, 8-10, 15-16, 19, 21-23, 27-28, 30, 32-34, 37-38, 41-45, 48, 50-52, 57- 
58, 61 and 63-65 were rejected under 35 U.S.C. 102(e) as being anticipated by Carter (U.S. 
Patent No. 6,201,61 1). Applicant respectfully disagrees. 

Applicant does not see a two-way communication channel between the server 103 
and the printer 105 of Carter. There is no description of communication in both directions 
between the server and the printer through the thin client 101 of Carter. In Figure 3 of 
Carter, it is seen that information flows only in one direction from the server 103 to thin 
client 101 to the printer 105. At most, this maybe considered as a one-way communication 
channel between the server 103 and the printer 105 of Carter. Figure 4 shows that the printer 
router of the server sends a PRF (printer-ready format) job to the print receiver of the thin 
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client (227), the printer receiver receives the PRF job (229) and sends the PRF job to the 
printer (231). Thus, Carter only teaches to send the print job in the PRF format information 
from the server to the printer in one direction. There is no description of communication in 
both directions between the server and the printer in Carter. 

It is understood that the system of Carter is very different from the subject matter as 
claimed. Carter teaches to use a remote server to convert the print job from a device- 
independent format (DIF) into a printer-ready format (PRF). The thin client generates the 
print job. After the server of Carter translates the print job from one format to another, the 
server of Carter returns the job back to the thin client, which then sends it to the printer for 
local printing. Thus, there is only one-way communication from the server to the printer. 
Therefore, claims 1, 6, 19, 30, 41, 48 and 61 are patentable over Carter, since these claims 
recite the limitation of "two-way communication channel." 

Further, there is no description in Carter suggests that the printer 105 is under the 
control of the server of Carter, since the server of Carter only translates the print job for the 
client. In Carter, the DIF (device-independent format) producer 109 of the thin client 101 
generates the print job in the DIF format, which is then translated by the server of Carter into 
the PRF format. However, claim 2 recites: 

2. (previously presented) A method to operate a peripheral device, the 
method comprising: 

receiving at a server an instruction from a remote device to operate the 
peripheral device , the peripheral device being connected to a 
port of the remote device; 

in response to the instruction , the server: 

generating control information recognizable by the peripheral 
device when applied onto the port; and 
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communicating the control information to the remote device 
for applying onto the port of the remote device to. 
operate the peripheral device under control of the 



server. 



In one embodiment of the present invention, the portable device displays the image that is 
rendered on the server from the entire web page. The image, not the web page itself, is 
transmitted to the device for display. Thus, the device does not need the complicated 
software to render the web page. Further, when a print message is sent to the server, the 
application running on the server, not the portable device, generates the print job. Since the 
printer connected to the portable device is under the control of the server, through the two- 
way communication channel, the server controls the printer of the portable device to print the 
web page. The portable device does not send the web page to the web server to print. The 
portable device does not generate the print job for the server to translate. However, Cater 
teaches to use the server as a network tool to translate the print job for the thin client. The 
server of Carter translates the print job without operating the printer under the control of the 
server in response to the instruction to operate the printer. Thus, at least for the above 
reasons, claims 2, 15, 27, 37, 44 and 57 are patentable over Carter. 
Further, for example, claim 9 recites: 

9. (currently amended) The method of claim 8, wherein the instruction 



from the remote device requests to print a document; the server 
generates the control information according to the document for 
printing using the printer; and, the document is not received from the 
remote device. 
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However, the server of Carter translates the print job, which is received from the thin client. 
Similarly, claims 22, 33, 42, 51 and 64 are patentable over Carter, since these claims recite 
the limitation of "the document is not received from the remote device." 

Since dependent claims incorporate the limitations of the claims from which they 
depend, claims 1-68 are patentable over Carter at least for the above reasons. 

Claims 5, 18, 29, 40, 47 and 60 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over Carter. Applicant respectfully disagrees. For example, claim 5 recites: 

5. (previously presented) The method of claim 2, further comprising: 
generating at the server an image showing options to operate the 

peripheral device; 
transmitting the image from the server to the remote device for 

display; 

receiving at the server from the remote device data specifying user 

input relative to the image; and 
applying at the server one or more options to operate the peripheral 

device according to the data specifying the user input relative 

to the image. 

The Office Action asserted that, from the description of Carter, it would be obvious to store 
the printer application on the server, and thus to send print option images from the server to 
the portable device for selection. However, such modifications are well beyond the scope 
and teaching of Carter. The modifications suggested in the Office Action would involve 
much more than a print subsystem. In the context of Carter, there is no evidence that it is 
advantageous to move the printer application onto the server, since such a modification 
requires complications in other subsystems and other client and server relations. If the 
desirability and advantages were obvious, Carter would have described or suggested such an 
embodiment. However, to meet the objective as stated in the summary section, Carter only 
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suggested using the server to translate the print job for the thin client. Thus, Carter teaches to 
modify only a portion of a print subsystem. Carter teaches running application programs on 
the thin client, which generates the print job in a device-independent format (DIF) on the thin 
client. The thin client needs graphics API (107), on top of which applications (106, 106', 
106") run. The thin client needs a print driver (109) to produce the print job in the DIF 
format. The thin client uses the network server to translate the print job. If the printer 
application were moved to the server, it would not be clear what is the scope of "printer 
application" and how it relates to other applications that require printing capabilities. 
Furthermore, it would not be clear how the print options would be collected at the server. 
There is no suggestion of collecting print options through sending images of GUI interfaces. 
Thus, from such a description of Carter, it would not be obvious to make these modifications 
suggested in the Office Action for the rejection of claims 5, 18, 29, 40, 47 and 60. 

Claims 7, 20, 31, 49 and 62 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over Carter in view of Maniwa (U.S. Patent No. 4,768,483). Applicant 
respectfully disagree. For example, claim 7 recites: 

7. (currently amended) The method of claim 6, wherein the peripheral 
device comprises a scanner; and the control information is applied to 
operate the scanner . 

Carter teaches to use a network server to translate a print job for the printer of a client. 
However, such a teaching is not applicable to a scanner. If the teaching of Carter were 
applied to a scanner, the network server would be used to convert a "scan job" from one 
format to another before sending to a scanner, which does not make sense. It is understood 
that the application programs do not generate "scan job" in a similar fashion as for a printer. 
Applicant respectfully submits that it is the teaching of the present invention to establish the 
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two-way communication channel so that the server can control the peripheral device attached 
to the client, as discussed above. The teaching of the present invention can be applied to a 
scanner. However, the teaching of Carter is not generally applicable to a scanner. 

Claims 1 1-12, 14, 24-25, 35-36, 53-54, 56 and 66-67 were rejected under 35 U.S.C. 
103(a) as being unpatentable over Carter in view of Koga (EP Patent No. 1,026,578). 
Applicant respectfully disagrees. In one embodiment of the present invention, the portable 
device does not render web pages into images for display. The server renders a web page 
that is requested by the portable device into an image. The image is sent from the server to 
the portable device for display. When the user of the portable device wants to print the web 
page, the portable device sends a message, not a print job, to the server. The server generates 
the print job from the web page in response to the message. Since the server has a two-way 
communication channel to control the printer, the server prints the web page on the printer, 
which is attached to the portable device. For example, claims 1 1 and 12 further recite: 

1 1 . (previously presented) The method of claim 2, further comprising: 
receiving at the server a request from the remote device for a 

document; 

rendering at the server the entire document into an image; and 
transmitting the image in a compressed format from the server to the 

remote device for display; 
wherein the instruction from the remote device is in connection with 

the image. 

12. (previously presented) The method of claim 11, wherein the peripheral 
device comprises a printer; and, the instruction comprises a print 
command to print the document . 
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However, the default properties for print jobs and for the printer do not correspond to the 
document that is requested by the portable device for display. A graphical user interface for 
manipulating the properties cannot be considered as rending the entire document into an 
image. The default properties are used to control the generation of print jobs in a print-ready 
format. These properties are received at the client for the initialization, not for display on the 
client. Further, these default properties are used by the server to convert the print job from a 
device-independent format to the print-ready format. These properties are not the document 
to be printed. It is not clear how and why to print a user interface that sets the print options 
for a print job. Thus, the elements of the cited references do not correspond to the claim 
limitations. 

Although Koga teaches to use a web based printer configuration system, the user 
interface is based on HTML. In Koga, the Internet browser running on the client, renders the 
HTML for display. The web server of Koga does not render the HTML into an image. A 
web page in HTML is not an image. 

Claims 13, 26, 55 and 68 were rejected under 35 U.S.C. 103(a) as being unpatentable 
over Carter, in view of Koga and further in view of Mogul (U.S. Patent No. 6,243,761). 
Applicant respectfully disagrees. For example, claim 13 recites: 

13. (previously presented) The method of claim 1 1, wherein the document 
represents a web page having links; and, said transmitting the image 
comprises: 

dividing the image into a plurality of sections ; 

compressing the plurality of sections into a plurality of compressed 



sections respectively; and 
transmitting the plurality of compressed sections to the remote device 
in a sequence according to a display priority. 



05965.P012 



-- 26 ~ 




The Office Action asserted that "both compressing images sent over the web, and 
transmitting portions of a web page to a client in priority order are well known". However, 
claim 13 recites "dividing the image into a plurality of sections", where the image is rendered 
at the server from the entire document . Dividing such an image that is rendered from the 
entire web page is no described in Mogul. Mogul teaches to adjust the content of web pages 
at their sources so that the pages can be optimally rendered at destination depending on 
effective network condition (e.g., Col. 1, lines 8-12, Mogul). Thus, as in a traditional 
approach, the client, not the server, renders the web pages for display in Mogul. It is 
understood that a web page may include a number of embedded images, text and other 
components. The web page generally specifies the content but not the exact image of the 
entire page. A browser is generally used to determine the exact image of the entire page 
through rendering the web page. Rendering a web page for display is a complex process, 
which typically requires a sophisticated software application program (e.g., Internet Explore, 
or Netscape browser) and a powerful processor to obtain a good quality rendering result. 
According to Mogul, the components of the web page, such as the embedded graphics 
images, may be adjusted to reduce the size, the resolution and the number of colors (e.g., Col. 
4, lines 40-43, Mogul). However, Mogul does not suggest rendering the entire web page, 
including links, into an image, which is then divided into sections for transmission according 
to display priority. 

Thus, Applicant respectfully submits that the pending claims are patentable over the 
cited references. 

Please charge any shortages or credit any overages to Deposit Account No. 02-2666. 
Furthermore, if an extension is required, Applicant hereby requests such extension. 



Respectfully submitted, 
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Lehua Wang 
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